It is known for at least one coprocessor to be provided in a contemporary data processing system, wherein the coprocessor is configured to perform data processing operations on behalf of a main (or “host”) processor. The main processor maintains overall control of the data processing system, but delegates specific tasks to one or more coprocessors. Typically such coprocessors will have a dedicated function in the data processing system, for which they are explicitly designed and optimised, such that they may carry out the tasks delegated to them by the main processor with great efficiency. Known examples of such coprocessors are a video engine configured to handle the processing of video data and a direct memory access unit (DMA) configured to handle memory accesses (in particular translating between virtual addresses and physical addresses by means of a memory management unit). Furthermore, it is known for such coprocessors to be arranged in a nested fashion, wherein a coprocessor itself may have dedicated components for performing specific tasks within it, such as hardware accelerators, microcontrollers and so on.
A given coprocessor may be allocated tasks to carry out on behalf of the main processor for which different configurations of the coprocessor are necessary. For example, in a given processing session the MMU used by a coprocessor may be configured with a certain page table base address indicating the location in memory of the page table storing the mappings between virtual addresses used in that processing session and the corresponding physical addresses in memory. These mappings may be important because they can define security boundaries in the system, allowing one processing session access to a particular area of memory, whilst hiding that area of memory from another processing session. For this reason, when one processing session ends (or indeed crashes) it is necessary for the main processor to reset the coprocessor, so that the configuration of the MMU is such that the next processing session has the correct view of memory, and is not allowed to see a view of memory intended only for the previous processing session. Other configuration data of the coprocessor may also need to be reset, as well as clearing temporarily stored data such as the contents of local caches.
FIG. 1 schematically illustrates such a data processing system 100, comprising host processor 105, coprocessor 110 and system memory 115. The coprocessor 110 can be seen to comprise a set of coprocessor engines 120 and an MMU 125. Coprocessor engine 120 comprises a hardware accelerator 130, a microcontroller 135 and a DMA unit 140. The coprocessor engine 120 accesses system memory 115 via MMU 125. The configuration of MMU 125 (defined in configuration registers 145) is determined by host processor 105, which writes the required configuration data into the configuration registers 145. This enables the host processor to maintain control over the view of system memory 115 that each of the coprocessor engines 120 has. In particular, host processor 105 writes a different page table base address into one of the configuration registers 145, depending on the processing session being carried out by coprocessor 110. MMU 125 further comprises a translation look aside buffer (TLB) 150, which caches translations between virtual addresses and physical addresses previously made by the MMU 125. The MMU 125 has previously retrieved those translations from the page table in system memory 115 indicated by the page table base address stored in configuration registers 145. When coprocessor 110 completes a processing session, and will be required to start another processing session, host processor 105 issues a reset signal (“RESET”), which causes the coprocessor engines 120 to flush their local caches (and any other session specific information) and causes MMU 125 to flush TLB 150. Host processor 105 writes a new set of MMU configuration data into the configuration registers 145, in particular writing a new page table base address appropriate for the next processing session. Coprocessor 110 can then begin the next processing session.
However, whilst the above described arrangement allows the host processor to ensure that the coprocessor has the correct view of the system memory depending on the processing session being carried out by the coprocessor, this arrangement can result in undesirable delays between processing sessions on the coprocessor, as is now described with reference to FIG. 2. In order to set up a first processing session on the coprocessor, the host issues a set of signals 200, comprising a reset signal, the required MMU configuration data, and a signal to start the processing session. The coprocessor then performs its processing 210, at the end of which it signals to the host (e.g. an interrupt signal IRQ) that it has finished processing. There will then follow a latency delay 220 whilst the host reacts to the signal indicating that the first processing session has finished and then performs the same sequence of actions 230 to set up a second processing session on the coprocessor, namely a reset signal, MMU configuration data and a start processing signal. The coprocessor then begins its second processing session 240. It can be seen from FIG. 2 that due to the turn-around latency 220 and the time 230 required to set up the second processing session on the coprocessor, there is a period between the first processing session 210 and the second processing session 240 in which the coprocessor is idle
A similar delay is also apparent in the situation where a first processing session on the coprocessor crashes. In this situation, it is necessary for the host processor to have some mechanism for recognising that the first processing session has crashed (e.g. the absence of some update data or a time out), following which the host processor must respond to the recognition that the first coprocessing session has crashed, and perform the same set of actions (reset, new MMU configuration data and start processing) as described above.
It is further known for a coprocessor to be provided with a reset controller associated with the coprocessor, which the host processor can instruct to cause the coprocessor to reset or which software on the coprocessor can interact with and thereby request a reset. Examples of such reset controllers are that discussed in the document “AT91 Reset Considerations” (available at http://www.atmel.com/dyn/resources/prod_documents/DOC2645.PDF) and the SMR101 programmable reset controller (more information available at http://www.summitmicro.com/prod_select/summary/SMR101/SMR101.htm).
However, when such reset controllers initiate a reset of coprocessor components it is still necessary for the host processor to be responsible for setting up a new configuration of the coprocessor for its next processing session, which will involve the above-discussed delay.
It would be desirable to provide an improved technique for handling the resetting of a coprocessor, in a particular when the coprocessor switches from one processing session to a next processing session.